IBIS Macromodel Task Group Meeting date: 02 February 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Avago (LSI): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: * Steve Parker Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. -------------------------- Call for patent disclosure: - None. ------------- Review of ARs: - Ambrish to find and post the latest version of his Back Channel proposal. - Done. The most recent version is draft #14, which was posted to the IBIS ATM work archive on September 19, 2014. - Walter to find and post the latest version of his co-optimization proposal. - Done. The most recent version was posted to the IBIS ATM work archive on April 21, 2015. Note: ATM Work archive can be found here: http://ibis.org/macromodel_wip/archive-date.html ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Discussion of language corrections regarding "ground": - Discussion: Mike L. noted that we had originally discussed the idea of producing a 6.2 version of the spec with only the reference node language corrections. The goal had been to quickly produce the new version so that additional changes could then be made with 6.2 as the base. Mike was concerned that if the reference node discussions bogged down and 6.2 were to drag out, then there would be pressure to put other things into 6.2. Mike expressed concern that the ATM group might soon be running out of time to deal with this topic exclusively, if the Back Channel and Redriver flow BIRDs were about to become active again. He suggested that we might want to restart the editorial committee meetings held on Fridays and move the reference node discussions there. Ambrish noted that he was actively working on the Back Channel proposal again. Fangyi also noted that he had made progress on the Redriver proposal and would be ready to discuss it soon. Walter asked if he could first make a brief presentation regarding the reference language cleanup, which would then affect a decision to move the discussions to an editorial meeting. - Walter: [Reviewing the slide 2 of last week's presentation] - If we say IBIS is a measurement standard, and it defines how you hook up a device to test equipment, or how you run a simulation that is acting like a test equipment measurement, and how to make measurements and define your ground, then IBIS actually does that right. - One could fine tune the wording a bit, but IBIS generally defines the measurement process well. - IBIS does not tell you how to use the model that results, and I was proposing last week that if we wanted to have IBIS describe what to do with a "device in action" then we needed to define additional things. - I've now concluded we shouldn't start trying to have IBIS describe that. - It would lead to endless discussions. - If we just limit ourselves to thinking of IBIS as a description of a device under test, then the IBIS language is already essentially correct, and the intention is certainly clear. - [reviewing this language from the spec]: "The DUT die shows all of the available power and ground pin reference voltage terminals. For many buffers, only one power pin and one common ground pin terminal are used. The absolute GND pin is the reference for the V_fixture voltage and the package model equivalent network. It can also serve as a reference for C_comp, unless C_comp is optionally split into component attached to the other reference voltages." - This is saying that for most buffers you just have [Voltage Range] and don't specify [Pulldown Reference]. - "absolute" is confusing. If that said "common GND pin", then it has defined it as the reference for V_fixture, C_comp, package model. - Everything here is actually right. "absolute" is confusing. - We don't have to talk about how to use Models. If we all agree that this is the approach we should take, then it's really just going to be an editorial task to scrub the document. - As soon as you realize ground is always used in the context of a test fixture ground, we can leave it up to the EDA tool to hook things up in a logical way when it's not a DUT. We don't have to describe that. - Mike L.: This makes me think it should go to the Friday editorial meeting. - Arpad: Before we discuss Friday logistics, I would like to discuss what Walter is suggesting. If we agree, then we can move it to Friday. - Discussion: Bob said that he didn't mind the suggestion to use the language "common ground" instead of "absolute", but he stated the ground should be what the buffer saw, not the Pin. He was worried about de-embedding the package effects since he said it's a device characterization. Arpad asked about actual measurements vs. simulated measurements, since it might be hard to bypass the package in a lab measurement. Walter felt that the IBIS spec properly defined everything such that all measurements could be made and any de-embedding requirements would be unambiguous. Radek did not agree with Walter's new suggestion to adopt the position that IBIS only defines the measurements. He said describing the measurement was one part, but the purpose was to establish the data to be used in the behavioral model. Simulation is directly linked to a behavioral model being useful, so the IBIS spec should address both. He felt this discussion was primarily interested in how the model should be interpreted to get an unambiguous simulation from the model data. He said portions of the task could be editorial, but we still have the issue of [Pullup Reference], etc., and their relationship to this local ground. The "absolute" ground language can be replaced by "common" or GND, but we still have to make sure we know what/where is the local ground reference for that specific buffer. When we are doing a simulation with different local grounds for different buffers, that's the issue that needs to be addressed. Radek again suggested that we might extend the Pin Mapping keyword with a new column or add a new keyword to identify the ground pin for each buffer. Walter agreed that Radek's suggestion of adding the new keyword would make the behavioral model better. He suggested it might be done as a separate BIRD. Bob again expressed his concern that adding specification of this local ground reference would cause problems. He said the existing spec was fine for the DUT, and worried that adding the new reference node risked breaking older models. Radek said the proposal would not affect older models, and suggested that it would allow model makers to specify the common ground location. If it weren't specified, then we might fall back on rules for interpreting the model, but it is best to give the model maker the ability to specify the reference. Walter noted that existing models didn't even have the ambiguity unless pd_ref and gc_ref were non-zero. Arpad expressed concern for the language, and suggested "common reference" instead of "common ground". Radek was fine with this, but Walter didn't feel the "common ground" language was problematic since we were specifying the local reference from which any non-zero voltage values in pd_ref, pu_ref, etc. were measured. - Arpad: We are at the time limit. - Let's think about coming up with the right word for the common reference. - Let's also think about Walter's question about whether we can reduce the ground language cleanup task to an editorial effort if we treat the current IBIS spec as defining measurement only. ------------- Next meeting: 09 February 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives